To combat fraud or other malicious behaviors, modern enterprise networks employ a series of multiple reporting devices that indicate potential malicious behavior, through a variety of channels. For example, a webserver hosting an enterprise website may report failed login attempts, while firewalls may report blocked data traffic arriving from untrusted Internet Protocol (IP) addresses. In existing security solutions, the various devices may produce alerts containing potential threat or vulnerability information associated with their respective channels. These alerts are then assigned in a work-queue to an appropriate engineer or fraud analyst who is tasked with addressing the particular alert. In a fraud detection context within a financial institution, these alerts can often be associated with a customer, where fraud analysts can sometimes identify an attack theme, or “scenario,” across multiple alerts, provided the alerts arrive in the working-queue in quick succession.
One problem with this basic queuing approach in the conventional technology is managing volume. The sheer volume and growth of alerts presents an operational challenge to detection and analysis of alerts. In many large enterprises, the daily alert volume across all customers can be in the thousands, tens-of-thousands, or hundreds-of-thousands, depending on the size of the enterprise. The volume of alerts generated often exceeds the capacity of the personnel. This results in a significant portion of alerts expiring or not reaching a final disposition of “fraud” or “not fraud.” To help ease the burden of volume, existing technology executes fraud detection rules that attempt to assign incoming alerts to one or more scenarios. However, these technological solutions have their own shortcomings, as automated fraud rules become yet another contributor to the volume. The deployment of new fraud rules increases the alert volume or working-queue volume because there is some overlap with existing fraud rules. One fraud rule might assign an alert to one working-queue for a first scenario, while a second fraud rule might assign the same alert to another working-queue for a second scenario. Thus, this automation may help assign alerts to an appropriate queue, but ultimately fail to reduce the overall volume of alerts.
Furthermore, security engineers and fraud analysts often interact with enterprise case management software that logs, monitors, and manages personnel efforts to mitigate alerts. Conventional case management software can tap into working-queues and alerts that are stored into databases that receive and store alerts from, in some cases, multiple alerts were generated in multiple queue for each customer, making it difficult to achieve situational awareness and determine the optimum alert priority to maximize fraud-loss prevention.
Additionally, the sheer volume of alerts also creates a technical problem for the enterprises. Identifying and processing a large volume of alerts requires high processing power. This is highly undesirable because the enterprises have to designate a large portion of their computing infrastructure to processing the alerts, which is inevitably expensive. Furthermore, processing a large number of the alerts, even given today's processing capabilities of the computers, may cause undue delays in the alert determination, which is also highly undesirable because, if not detected in a timely manner, a fraudulent transaction can damage the enterprises' computer infrastructure.